An ITMS-91061: Missing privacy manifest rejection email looks as follows: ITMS-91061: Missing privacy manifest- Your app includes "<path/to/SDK>", which includes , an SDK that was identified in the documentation as a privacy-impacting third-party SDK. Starting February 12, 2025, if a new app includes a privacy-impacting SDK, or an app update adds a new privacy-impacting SDK, the SDK must include a privacy manifest file. Please contact the provider of the SDK that includes this file to get an updated SDK version with a privacy manifest. For more details about this policy, including a list of SDKs that are required to include signatures and manifests, visit: https://developer.apple.com/support/third-party-SDK-requirements. Glossary ITMS-91061: Missing privacy manifest: An email that includes the name and path of privacy-impacting SDK(s) with no privacy manifest files in your app bundle. For more information, see https://developer.apple.com/support/third-party-SDK-requirements. : The specified privacy-impacting SDK that doesn't include a privacy manifest file. If you are the developer of the rejected app, gather the name of the SDK from the email you received from Apple, then contact the SDK's provider for an updated version that includes a valid privacy manifest. After receiving an updated version of the SDK, verify the SDK includes a valid privacy manifest file at the expected location. For more information, see Adding a privacy manifest to your app or third-party SDK. If your app includes a privacy manifest file, make sure the file only describes the privacy practices of your app. Do not add the privacy practices of the SDK to your app's privacy manifest. If the email lists multiple SDKs, repeat the above process for all of them. If you are the developer of an SDK listed in the email, publish an updated version of your SDK that includes a privacy manifest file with valid keys and values. Every privacy-impacting SDK must contain a privacy manifest file that only describes its privacy practices. To learn how to add a valid privacy manifest to your SDK, see the Additional resources section below. Additional resources Privacy manifest files Describing data use in privacy manifests Describing use of required reason API Adding a privacy manifest to your app or third-party SDK TN3182: Adding privacy tracking keys to your privacy manifest TN3183: Adding required reason API entries to your privacy manifest TN3184: Adding data collection details to your privacy manifest TN3181: Debugging an invalid privacy manifest

In this post, we'll share tips to help you submit apps that deliver original ideas to your users. When working on your app, focus on creating interesting, unique experiences that aren't already available. Apps that actively try to copy other apps won't pass review, and accounts that repeatedly submit copycat apps or attempt to impersonate a service will be closed. The rules that prevent copycat and impersonator apps from being distributed on the App Store are described in App Review Guideline 4.1: 4.1 Copycats (a) Come up with your own ideas. We know you have them, so make yours come to life. Don’t simply copy the latest popular app on the App Store, or make some minor changes to another app’s name or UI and pass it off as your own. In addition to risking an intellectual property infringement claim, it makes the App Store harder to navigate and just isn’t fair to your fellow developers. (b) Submitting apps which impersonate other apps or services is considered a violation of the Developer Code of Conduct and may result in removal from the Apple Developer Program.(c) You cannot use another developer’s icon, brand, or product name in your app’s icon or name, without approval from the developer. These requirements help make the App Store both a safe place for people to discover apps and a platform for all developers to be successful. Best Practices Here are three best practices that will help you submit apps that follow App Review Guideline 4.1: 1. Submit apps with unique content and features. People want apps that provide unique experiences. Find areas that aren't currently being served and build compelling apps for those audiences. Do: Create apps that provide a new experience or a unique spin on an existing concept. Design original, delightful interfaces that elegantly meet your user's needs. Don't: Don’t imitate the features and functionality of other apps. Don’t copy the look and feel of other apps, such as using an identical user interface design. 2. Make sure App Store metadata only contains relevant information and content you either own or have permission to use. The metadata provided in App Store Connect is used to populate your app's product page on the App Store. People rely on this metadata to learn about your app and what it has to offer. Leveraging the popularity of another brand or app, either by including irrelevant references or protected content, is misleading and won't help your app succeed. Do: Use engaging, descriptive language to describe your unique app. Create original content that best represents your app, such as screenshots showing the actual app in use. Don't: Don't use protected material you do not have the necessary permission to use, such as app icons that are similar to icons of a popular app. Don’t include irrelevant references, such as popular app names or trademarked terms, in any metadata fields. 3. Provide information that is authentic and verifiable. People want to know the developers behind their favorite apps are who they say they are. It's important to continually review and provide up-to-date information, including the developer or company name listed on your Apple Developer Program account, the Support URL listed on your app's product page, and other helpful information. This will enable your users to contact you when they need help and it will also hinder people who may try to impersonate you, your app, or your service. Do: Make sure all information, resources, and documentation related to your account and apps are current and accurate. Don't: Don’t provide inaccurate information or resources, such as directing people to outdated support pages. Don’t provide fraudulent documentation. Accounts that submit fraudulent documentation will be removed from the Apple Developer Program. Support Incorporating these best practices into your app's development will help you submit apps that follow App Review Guideline 4.1. If you need additional assistance, consider taking advantage of one of the following support options available from App Review: If your submission has been rejected, reply to the message from App Review in App Store Connect and request clarification. Request an App Review Appointment to discuss the results of our review. Appointments are subject to availability, and take place during local business hours in your region on Tuesdays and Thursdays. If you believe your app follows the App Review Guidelines, consider submitting an appeal to the App Review Board. Resources Learn about foundational design principles from Apple designers and the developer community. Learn how to create engaging App Store product pages. Note that apps that violate intellectual property rights are subject to removal through the App Store Content Dispute process. If you believe an app on the App Store violates your intellectual property rights, you can submit a claim.

Hi everyone, I would like to ask if anyone else has experienced a longer-than-usual "In Review" phase recently. Here is the timeline for our app, App ID: 6800282515: Submitted for Review: Sep 14 at 05:00 Pacific Time Checked and found status in "In Review": Sep 14 at 19:00 Current Status: Still "In Review" (as of Sep 17, 19:00+) It has been in the "In Review" state for over 3 full days without any updates, rejection notices, or requests for additional info. Has anyone run into a similar issue lately? Is there any recommended way to handle this, or should we just wait a bit longer? Any advice would be greatly appreciated!

Hi everyone, I submitted my app for App Review on August 14, 2026, at 2:39 PM. I later submitted an updated version again on September 9, 2026. The latest submission has been showing “In Review” for the past 5 days, but I still haven’t received any review decision or additional information from the App Review team. As I understand it, once an app enters the “In Review” status, a review decision is generally provided after the review is completed. However, in my case, the status has remained unchanged for several days. Has anyone experienced a similar situation recently? Is it normal for an app to remain in “In Review” for this long, or is there anything I should do from my side? Any advice or guidance would be appreciated. Thank you!

Hi all — hoping someone here has run into this and can point me in the right direction. I'm a solo, independent developer (not a company) submitting my first app, a directory app connecting coaches with vendors for sports equipment/services. I've been rejected three times now under Guideline 5.6 (Developer Code of Conduct), with the exact same wording each time: "We've identified a pattern of unusual behavior with the app that is commonly associated with fraudulent activity. Specifically, the app contains features that appear to have been intentionally hidden during the review process." Here's what I've done in response to each rejection: 1st rejection: I realized I hadn't shown an optional "Upgrade to Pro" feature (an external Stripe checkout link for vendors) in my review demo video, and Apple flagged it as hidden. To comply with Guideline 3.1.1, I removed that feature from the iOS app only, using a flag that checked which platform loaded the page, while leaving it on the website. 2nd rejection: Same 5.6 language again. My best guess was that showing different behavior between the app and the website (based on that platform flag) was itself what looked like "hidden/manipulative" behavior to review, even though my intent was just 3.1.1 compliance. So I removed the feature completely and identically everywhere — no platform-specific code at all anymore, on the app or the website. 3rd rejection: Same exact wording again, even after that fix. I also separately found and fixed an unrelated issue — a footer "Admin" link that was visible to all users (including signed-out visitors) but non-functional unless the account was flagged as admin — in case that was contributing, and hid it for all non-admin accounts. I've replied in the Resolution Center each time explaining my fixes, and on the most recent reply I directly asked the review team to tell me specifically what feature they're seeing as hidden, since I no longer have anything left in the app that I can identify as behaving inconsistently. I got the same templated rejection language back, with no specifics. I'm currently waiting on a callback from Apple Support, but wanted to ask here in the meantime: has anyone dealt with a 5.6 rejection that kept repeating with no specifics, and found a way to get an actual answer on what's being flagged? Is there a more effective way to word a Resolution Center reply, or a different channel (App Review Board appeal, etc.) that actually gets a specific response instead of the same boilerplate? Any advice from anyone who's been through this would be a huge help. Thanks in advance.

Hi everyone, I was slowly working on an app for many years, five to be precise. It was a long way, with a custom video engine, chat UI, and a lot of life stuff in between, and I finally submitted it to the App Store last month. The idea of the app is that you can create videos that show a chat conversation, with animated text bubbles, text, typewriter effects, and so on. See an example: It is not a unique concept. I found many apps on the App Store like TextingStory and ChatTales, and many general-purpose video editors like CapCut, Canva, or Mojo have video templates that allow you to create similar chat videos. So conceptually, nothing really worried me. But my first submission got a 1.1.6 rejection: Guideline 1.1.6 - Safety - Objectionable Content Issue Description The app includes trick or joke functionality which is intended to or may be used to deceive users. Specifically, the app allows users to create fake chat conversations. Please note that adding a disclaimer to the app description is not sufficient if the rest of the metadata and the app could be misleading. Next Steps Revise the app so that it may not be used to deceive users. As a follow-up, I explained the app’s positioning as a video tool, as I believed this was some misunderstanding. The app is clearly focused on storytelling and creating videos. The output video is also not really trying to imitate an actual messaging screen, as it doesn’t contain UI chrome such as a status bar, navigation bar, text input controls, timestamps, or delivery/read receipts. So I updated the app and metadata to present the storytelling and video export purpose more clearly. After about 10 days waiting for the second review, I got essentially the same rejection: The app still creates fake chats. I am now trying to clarify with App Review what exactly can be changed. My hope is that removing features like "New Project from screenshots" and visual themes resembling existing messaging apps could help. But the biggest worry is that the category itself banned and the app won't be accepted at all. So I wonder if anyone here has experience dealing with a 1.1.6 rejection like this. The relevant part of the guideline says: False information and features, including inaccurate device data or trick/joke functionality, such as fake location trackers. Stating that the app is “for entertainment purposes” won’t overcome this guideline. Apps that enable anonymous or prank phone calls or SMS/MMS messaging will be rejected. Is producing chat style videos effectively forbidden as a category? As I mentioned there are existing apps, but as I understand that doesn't guarantee anything. What could distinguish a “fake chat” from a "non fake fictional chat video"? Has anyone had a similar rejection, and if so, what did Apple actually ask you to change?

Hello, My app, The Survivors: Mystery Story, was rejected under Guideline 1.1.6 because App Review considered the fictional phone interface, messages, calls, photos, and device-style elements potentially deceptive. The app is a fictional narrative mystery game. The simulated phone is part of the storytelling and cannot be used to make real or prank calls, send SMS/MMS, alter real device data, or interact with real people. After the rejection, I replied to App Review three times through App Store Connect. I provided: clarification about the app’s actual functionality, screenshots showing the main game menu, chapter progression, mini-games, characters, and other gameplay, examples of similar narrative mystery games currently available on the App Store that use fictional phone-style interfaces. It has now been more than 100 hours since my first clarification message, and I have not received any response from App Review. The app is currently in Ready for Review state with the option to Resubmit to App Review. My main question is: Should I resubmit the current app now, or should I continue waiting for App Review to respond to my clarification messages? Also, is it possible that App Review does not respond to clarification messages and expects the developer to resubmit instead? I want to avoid unnecessary repeated submissions, especially because the rejection message included an Extended Review warning. Any advice from developers who have experienced a similar situation would be greatly appreciated. Thank you.

Our app has been in “Waiting for Review” for more than 60 hours, and the review has not started yet. We are working against a critical delivery deadline, as the app is required for committed customer deployment. We have already submitted an expedited review request, but the status has not changed. Normally, our previous submissions have moved to review much faster, so we are concerned about the extended waiting time. Has anyone experienced a similar delay recently, particularly after submitting an expedited review request? If so, how long did it take before the status changed to “In Review”? We would appreciate any guidance from the App Review team, as the delay is now putting our scheduled delivery at risk. Thank you.

Hello App Review Team, Our app MagicMatch has been in "Waiting for Review" status for 7+ days now (submitted Friday, September 18). We previously addressed a Guideline 4.3(a) rejection and resubmitted with substantial changes to the app's structure and design. Could you please confirm: • Is there a specific reason for this extended hold? • Is any action required from our side? • When can we expect the review to proceed? We have not withdrawn or resubmitted the build during this wait, to avoid resetting the queue. Any update would be greatly appreciated. Thank you.

Good day, everyone. I am experiencing an issue where, when I upload my app to Apple for review, it gets rejected cos of a request login timeout, but when we try to reproduce the bug, we can't cos it goes smoothly here without the timeout. Has anyone experienced something like this, and how was it solved

Hi everyone, I'm posting here because I honestly don't know where else to get answers anymore. I've been trying to release my first app for about 2–3 months now, and the review process has been, frankly, a disaster for us. As a first-time publisher I've genuinely tried to do everything by the book — I've read the guidelines carefully, prepared reviewer notes, a demo account, sign-in instructions, everything that's recommended. But here's the pattern I keep running into: Every submission sits in "Waiting for Review" for around two weeks — currently even longer. I know the official expectation is that most apps are reviewed much faster, but that has never once been our experience. When the review finally happens, it stops at the first issue found. Instead of reviewing the whole app once and giving me a complete list of everything that needs fixing, I get exactly one rejection point, I fix it, resubmit — and then wait another two weeks just to learn about the next issue. If I got all findings in one pass, I could address everything in a single build. This one-issue-per-cycle loop is what turns a fixable week of work into months. Right now I've been waiting 2.5 weeks for a metadata-only change (updated store screenshots). No binary change at all. I've contacted App Review support to ask for a status update and have received no response. For context: the same app has been live on Google Play for several weeks and is doing well there. We're not trying to sneak anything past review — we want to comply. We just need to actually be told what to fix, ideally all at once, and to not lose two-plus weeks per iteration. So my questions: Is there any way to get a complete list of issues in one review pass instead of one rejection per cycle? Is a 2+ week "Waiting for Review" time normal right now, or is there something about our account/app that could be causing this? Is there any effective way to get a status update when support doesn't reply? (Expedited review requests haven't helped either.) I understand App Review has to handle enormous volume, and I'm not looking to bash anyone — but as a small developer, this process has been demoralizing. Any advice from people who've been through this, or any pointers from Apple folks who read here, would be hugely appreciated. Thanks.

My app has been stuck in “Waiting for Review” for more than five days, without any progress or communication from App Review. Unfortunately, this is not the first time. Some submissions move forward within a few days, while others remain waiting for a week or longer with no explanation or meaningful status update. For developers running an actual business, this is extremely frustrating. App submissions are not simply experiments or hobby projects. Releases, customers, marketing plans, bug fixes, and business commitments can all depend on the review process. I fully understand that Apple needs sufficient time to properly review applications, but leaving a submission sitting at **“Waiting for Review” for an extended period without even beginning the review is difficult to justify—especially without any indication of the expected timeframe. Apple provides developers with strict guidelines, deadlines, and requirements, and developers are expected to comply with them. It is reasonable to expect a similar level of predictability and communication from the review process. Has anyone else recently experienced apps remaining in “Waiting for Review” for 5–7+ days? If so, how long did it eventually take before the review actually started? I would also appreciate clarification from Apple regarding whether these extended waiting times are currently considered normal or whether developers should contact App Review after a certain number of days.

Hello, Our first submission was previously reviewed and we received feedback under Guideline 2.1 because the reviewer was unable to access the app due to a forced update issue. We fixed the issue completely, uploaded a new build, and resubmitted on Friday. The submission has now been in Waiting for Review for approximately 4–5 days with no further messages or requests. Could someone please confirm that the submission is correctly queued and that nothing else is required from our side? App: KIBAKI: Persian Community Submission ID: d1f921a3-9001-4ef2-a392-657860c437cd Current status: Waiting for Review Thank you.

Many years ago—back in the Windows 3.0 era and inspired by Michael Jackson’s then-popular "Black or White" music video—I wrote a harmless app that smoothly morphed one face into another. Now, in retirement, I ported the app to various platforms (including iOS) to stave off boredom and supplement my rather meager pension. Everything was going fine; the app received occasional updates without any issues. But yesterday, during a routine update, I received a shocking and terrible message from the App Store team. They claimed that the app or its metadata included content some users might find upsetting, offensive, or otherwise objectionable—meaning the app violated Section 1.1 of the App Review Guidelines. That section lists things I find absolutely horrifying, such as realistic depictions of people or animals being killed, sexual or pornographic material, and the like. In their verdict, the App Store team didn't bother to specify exactly what content was in violation or which specific rule it broke. This situation has left me depressed, wondering if I actually made a mistake and have been offending people with my app for over 30 years. Could anyone advise me on what to do? Apologies for the long-winded post, but this is a truly difficult situation for me. PS: Here is the link to the previous version of the app published on the App Store: https://apps.apple.com/app/face-video-morph-animator-hd/id1551050080

Hello App Review Team, I’m following up regarding our latest submission, which is currently in Waiting for Review. We have addressed the issues identified in the previous review and submitted a new build with the necessary fixes. We also submitted an expedited review request because we are hoping to make the updated version available to our users as soon as possible. Could you please check the status of our submission and let us know if anything else is required from our side? Thank you very much for your time and consideration. Best regards, Ninja Rift Team

My app was built and uploaded on my new organization accoun, apple Start rejection and asking for more detail, gradually misunderstand some of my features suspected its in app purchase and rejected the apps, after Claritying that, rejected for spam, I clarify and resubmi, but no response for morethan a week, I redesigned and rebuil and resubmitted the apps, but still more than 5days no respons, Please any solution?

Hi there, Recently I've created a beautiful drink logging app, Abvy. You log what you drink and it shows an estimate and a possible range of the alcohol in your system over the evening. It has plenty of disclaimers that the measurements are only estimates and to never use them for driving decisions Since 26 August I've had the same rejection six times: "marketed as a blood alcohol content calculator but does not have associated hardware... apps that rely solely on software... are not appropriate." Meanwhile Beta App Review approved all the builds submitted. I had an App Review appointment today. The rep read the same paragraph back to me and said to appeal, which I've done. It was really frustrating. The published 1.4 doesn't mention blood alcohol at all, and university and public-health apps with the same kind of estimate are on the store today (Stay in the Blue from the University of Michigan, Virtual Bar from the Foundation for Advancing Alcohol Responsibility). Not to mention dozens of other, apps who do the exact same thing but are approved. Has anyone actually got past this on the App Store side? What changed for you? What can I do to fix this? Really care about Abvy and think it's an amazing app.

Hi, hoping someone can help with this. I submitted my app on Friday and it was initially rejected asking me to update the privacy policy. I made the changes straight away and resubmitted it. It was then reviewed again and I received another message asking me to confirm whether the pricing was correct. It was, so I replied confirming this within about 20 minutes. Since then I haven’t had any update and it’s now been several days. As far as I can see, there’s nothing else I need to change or submit — they asked for clarification, I gave it almost immediately, and the review now seems to be stuck. The app is already live on Google Play and we’re holding off on marketing and properly launching it until the iOS version is approved, as we want to launch on both platforms together. At the moment, Apple approval is the only thing we’re waiting for. Has anyone had this happen before or know if there’s anything I can do to get it back in front of the reviewer? If anyone from App Review sees this and can help work out what’s happened with the review, I’d really appreciate it. Thanks

Hello Apple App Review team and fellow developers, I’m looking for some guidance regarding a Guideline 4.3(b) rejection for my app, VIVA Khoja. VIVA Khoja is not intended to be a general-purpose dating app. It was created specifically for the Khoja Shia Ithna-Asheri community, a relatively small and geographically dispersed community worldwide, with the goal of helping members find serious matrimonial connections within their community. We have invested several months of work, significant development time, resources and money into this project. The app was initially rejected under Guideline 4.3 earlier this year, around June. Following that feedback, we did not simply resubmit the same product. We spent months substantially improving and differentiating the application, its onboarding, its features and the overall matrimonial experience. Among other things, VIVA now includes: A limited number of profiles presented per day instead of unlimited swiping A structured Send Interest process instead of a casual swipe-based experience Mandatory identity/profile verification A dedicated focus on serious matrimonial introductions within a defined community Community-specific profile and compatibility information A dedicated matchmaker interface, allowing matchmakers to participate in the matrimonial process The possibility for users to display testimonials/recommendations from relatives or trusted people directly on their profile, adding a family and community dimension that is very different from a conventional dating app One aspect of the latest review was particularly confusing for us. The app remained in Waiting for Review for a relatively long period. When we eventually received the notification indicating that the app was being reviewed, the rejection followed only a few minutes later. Because of how quickly this happened, we checked our own application/server activity to better understand the review process. Based on the information available to us, we could not identify evidence that the reviewer had gone through the application or tested the main features during that review window. I completely understand that Apple reviewers may have internal tools or review methods that are not visible to developers, so I do not want to make assumptions about the process. However, after spending several months significantly modifying the product following the previous 4.3 rejection, receiving another 4.3 decision so quickly was understandably frustrating, because we are unsure whether the new experience and features were actually evaluated. I fully understand and respect Apple’s concern regarding saturated categories under Guideline 4.3(b). I am not looking to repeatedly resubmit the application without addressing the underlying concern. I genuinely want to understand what Apple expects from us. Could someone from App Review please help clarify: What specifically would VIVA need to change for Apple to consider the experience “meaningfully different or improved” under Guideline 4.3(b)? Would features such as community-specific matchmaking, a dedicated matchmaker experience, family/trusted-person testimonials, mandatory verification and limited daily introductions be considered meaningful differentiation? Is there a way to request a more detailed review of the actual application experience and its new functionality? Given that VIVA is designed for a defined global community rather than the general public, would Unlisted App Distribution be a more appropriate model? I have already submitted an appeal and contacted Developer Support. I am completely willing to make further meaningful product changes if necessary. My main objective is to understand the correct path toward compliance and to ensure that the current version of the app and its new features are properly evaluated. Thank you very much for any guidance or assistance.

Guideline 2.3.6 - Performance - Accurate Metadata Issue Description Please note that the app includes tips, tools, predictions or other information related to real money gambling, real money betting, or real money skill-based gaming, you must select "Yes" for "Gambling" in App Store Connect. Apps must be rated accordingly for the highest level of content that the user is able to access in the app. Next Steps Update the Age Rating selections in App Store Connect to select "Yes" for "Gambling." The Age Rating selections can be found on the App Information page after selecting the app in App Store Connect. I have had multiple releases with just having "Social Gaming" Set to Frequent as my app has wagering in it but can NEVER be exchanged for real currency which puts it in the bucket of SOCIAL GAMBLING/WAGERING. This reviewer has no idea how to interpret what Guideline 2.3.6 actually means and this reviewer keeps rejecting my app..... Apple can you please change the reviewer with someone who actually can comprehend what the guidelines means. Because in my privacy and tos I specifically state the words gambling and no in-game exchange or out of game exchange for real currency can occur - not sure why I fail the guideline only this ONE TIME because this reviewer cannot understand what the guideline means. This is holding up my app release for the gazilianth time and costing yourselves and myself money. APP ID : 6767430745

Hi Apple Developer Community, I'm hoping someone from the App Review community or Apple can help me understand what may be happening with our app. Our educational app has now been rejected multiple times under Guideline 5.6 — Developer Code of Conduct. The problem is that we have not received a specific explanation identifying which feature, behavior, or part of the app is considered a violation. We have carefully reviewed the rejection and made sure that there are no features intentionally hidden from App Review. The functionality available to the reviewer is available to normal users as well. We have already: Replied to the App Review rejection asking for the specific reason. Submitted an appeal explaining the situation. Asked Apple to identify the specific feature or behavior that triggered Guideline 5.6. However, we have not received a response to either the appeal or our message in the App Review/Resolution Center yet. About the app: This is an educational application used by students for exam preparation. The upcoming examination period is approaching, and students are currently waiting for access to the application and its preparation materials. This makes the situation particularly time-sensitive for us. We are willing to make any changes required by Apple, but without knowing what behavior triggered 5.6, we don't want to keep making random changes and repeatedly resubmitting the same app. My questions are: What kinds of situations typically result in a 5.6 rejection when Apple does not specify a particular feature? Is there anything specific we should check in our app or review configuration? Is there a way to obtain clarification on the exact 5.6 concern while the appeal is pending? Should we wait for the appeal response before submitting another build? We would really appreciate any guidance. We are not trying to bypass App Review — we simply want to understand the specific issue so we can fix it correctly and provide students access before their exams. Thank you.

What's the guidance on submitting new builds for App Review that include support for iPhone Duo/iPhone resizability? Will they work when building with Xcode 27 + if available for 27.1 or do we have to wait for new Xcode release? Any guidance from Apple and timeframe on build submission if our updates are ready and undergoing testing in simulator? Thank you.